Thanks a lot for tackling this.

@jongiddy I feel that libz-sys gets more complex by adding patch upon patch, and hoped you could involve yourself here more as well. Maybe you could help with making a case for using environment variables to alter build results, or for using Cargo Features. This is my related comment, to allow for backward compatible fixes for those who know about it.

Thanks everyone for your help.

Neither option is ideal.

Using an environment variable means there is a hidden dependency that affects the build. When anyone needs support, it is an extra relevant piece of information they need to supply. And it is easy to not be aware whether it is set or not.

Using a feature is painful when a transitive dependency is deeply nested, and libz-sys is typically deeply nested. You either need to pass the feature setting down through the intermediate dependencies or include the dependency in the top-level crate, even though it is not used directly.

Pragmatically, since there is already an environment variable for controlling static vs dynamic, I'd accept using an environment variable here. However, I suggest that the existing variable is reused, so that setting LIBZ_SYS_STATIC=0 always forces dynamic linking, even for the supposedly non-supported targets (e.g. target.contains("msvc")).

FWIW there is precedent in other -sys crates for disabling building of vendored C code/forcing use of system library through an env var:

• libgit2-sys: "LIBGIT2_NO_VENDOR": "1",
• libssh2-sys: "LIBSSH2_SYS_USE_PKG_CONFIG": "1",
• openssl-sys: "OPENSSL_NO_VENDOR": "1",
• pcre2-sys: "PCRE2_SYS_STATIC": "0",
• rustonig-sys: "RUSTONIG_SYSTEM_LIBONIG": "1",
• zstd-sys: "ZSTD_SYS_USE_PKG_CONFIG": "1",
• libsqlite3-sys: "LIBSQLITE3_SYS_USE_PKG_CONFIG": "1",

Thanks a lot for the summary, it's good to know the standards.

This PR is at a stage where the question remains if LIBZ_SYS_STATIC=0 can be used instead of introducing a new environment variable. On top of that, I think there should be a section in the crate-level docs to document this behaviour.

• pcre2-sys: "PCRE2_SYS_STATIC": "0",

This one is interesting. Matches the proposed one variable model with 0 meaning force dynamic and 1 meaning force static.

I'm hitting this when trying to cross-compile a project.
I have zlib1g-dev:arm64 installed on the host, but compilation fails because the compiler is called in a bad way - probably because it tries to statically link against a foreign architecture library (I see -lz).
The zlib-dependency is deep, so it´s not in the project's Cargo.toml.
Is there some way to work this around?

I think this patch is stuck on this question along with the implementation lacking discoverability as there are no docs at all.
Maybe the best discoverability could be achieved by putting typical compiler errors into the library docs, along with how to use certain environment variables to fix it.

I think this patch is stuck on this question along with the implementation lacking discoverability as there are no docs at all. Maybe the best discoverability could be achieved by putting typical compiler errors into the library docs, along with how to use certain environment variables to fix it.

Is there something I can do in the meanwhile to be able to cross-compile the project I'm looking at?

One could tell Cargo to use the patched version of the dependency (with [patch."crates-io"]) to make the environment variable override available.
Alternatively, one could pick up this PR and push it to completion.

One could tell Cargo to use the patched version of the dependency (with [patch."crates-io"]) to make the environment variable override available. Alternatively, one could pick up this PR and push it to completion.

In my case this does not seem to help.
I did

ENV target_host=aarch64-linux-gnu \
    target_host_rust=aarch64-unknown-linux-gnu \
    AR=${target_host}-ar \
    AS=${target_host}-as \
    CC=${target_host}-gcc \
    CXX=${target_host}-g++ \
    LD=${target_host}-ld \
    RANLIB="${target_host}-ranlib" \
    STRIP=${target_host}-strip \
    PKG_CONFIG_PATH="/usr/${target_host}/lib/pkgconfig" \
    PKG_CONFIG_SYSROOT_DIR="/usr/${target_host}" \
    LIB_SYS_TRY_SHARED=1
mkdir -p .cargo && \
                echo "[target.${target_host_rust}]" > .cargo/config.toml && \
                echo "linker = \"${target_host}-gcc\"" >> .cargo/config.toml && \
                echo "ar = \"${target_host}-ar\"" >> .cargo/config.toml && \
                echo "" >> .cargo/config.toml && \
                echo "[patch.crates-io]" >> .cargo/config.toml && \
                echo "libz-sys = { path = '/tmp/libz-sys' }" >> .cargo/config.toml && \
                cargo build --target="${target_host_rust}" --release

with zlib manually installed, just in case - and this in a Debian image:

__ZLIB_VERSION='1.2.13' && \
      ( cd /tmp && \
          wget -O /tmp/zlib-${__ZLIB_VERSION}.tar.gz https://zlib.net/fossils/zlib-${__ZLIB_VERSION}.tar.gz && \
          tar xf zlib-${__ZLIB_VERSION}.tar.gz && \
          rm zlib-${__ZLIB_VERSION}.tar.gz )

and I patch libz-sys by:

      ( cd /tmp && git clone https://github.com/rust-lang/libz-sys ) && \
      ( cd /tmp/libz-sys && wget -qO- 'https://github.com/rust-lang/libz-sys/pull/206.patch' | patch -p1 )

but it seems to not understand, and the aarch64 compiler is called with invalid flags

The following warnings were emitted during compilation:                                                                                                                                                                                                                                                                                                                                                 
warning: [email protected]: aarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-m64’
warning: [email protected]: ToolExecError: Command "aarch64-linux-gnu-gcc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I" "src/zlib" "-fvisibility=hidden" "-DSTDC" "-D_LARGEFILE64
_SOURCE" "-D_POSIX_SOURCE" "-o" "/boltz-backend/boltzr/target/release/build/libz-sys-2e1975913bc64b22/out/lib/0dc752f03a07a721-adler32.o" "-c" "src/zlib/adler32.c" with args aarch64-linux-gnu-gcc did not execute successfully (status code exit status: 1).cargo:warning=aarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-m64’

The project I'm trying to cross-compile (from amd64) is this one: https://github.com/BoltzExchange/boltz-backend.git

Maybe a different issue? The local override can also point to a local checkout of the crate, which might help to make adjustments to build.rs for a fix. Maybe something that can eventually be fully understood and contributed.

Yes, this was related to something else. I managed to cross-compile by overriding the dependency. Thanks. :)